Agent-based multithreading application programming interface

ABSTRACT

An application programming interface facilitates development of portable, multithreaded application programs. An application is a collection of instances of agent classes. Agent classes are organized in class hierarchies because new subclass agents may be derived from existing base class agents. Each agent class has its own message dispatching function; this allows the application programmer to alter the message passing framework provided by the application programming interface. Each agent instance within the program is independent because it is a sub-process aware only of its own data and context. Multithreading is provided by the application programming interface which contains a master dispatcher process non-preemptively allocating time to individual agents. Therefore, an application&#39;s multithreading capability is independent of the platform&#39;s operating system. In addition, a thread of execution may be split when the currently activated agent activates the master dispatcher. The application programming interface mediates between the system resources and the application, and maps the user interface of the application to the platform&#39;s chosen user interface. Therefore, the application and its user interface are portable.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of application programminginterfaces, and, more particularly to a system and method of writingportable multithreaded application programs by creating and combiningindependent agents.

2. Description of the Related Art

An application programming interface provides a method for programmersto write application programs that run on a particular hardware system.Typically an application programming interface is customized to run on aparticular hardware platform. An application programming interfaceprovides system calls to perform certain hardware dependent functionssuch as getting keyboard input or writing to disk. An applicationprogramming interface also provides calls for an application tointerface to the platform's user interface, for example, a call to opena window. Therefore, the application programmer can use the callsprovided by the application programming interface for performinghardware dependent and user interface functions. This saves theapplication programmer the time involved in writing hardware dependentand user interface functions; the application programmer need only writethe code specific to the application, and may rely on the calls providedby the application programming interface to perform system relatedfunctions.

An application program written for a specific application programminginterface cannot be ported to another platform with a differentapplication programming interface without replacing all of the systemcalls for the original application programming interface. It takes aprogrammer additional time to rewrite these sections of the applicationprogram. After the system calls are replaced, the application program isrecompiled. It will then run on the platform with the differentapplication programming interface. However, after the changes are made,the application program will then have the user interface look and feelof the programming interface on the new system. The same applicationprogram looks different on two different systems because the systemshave different user interfaces.

Furthermore, most application programming interfaces do not providemultithreading. Multithreading allows an application program to containmore than one stream of execution; each stream of execution is a thread.Typically, each thread performs a different function within theapplication program; for example one thread fills a buffer, and anotherthread reads from the buffer. The application programmer must then relyon the multithreading provided by the operating system on the platform.Some operating systems may not provide any multithreading at all.

In addition, application programming interfaces provide a scheme forsending messages among components of an application program. Forexample, when a character is entered at the keyboard, a message may besent to a window telling the window to display the character. Typicallyan application programmer cannot modify the message passing frameworkprovided by the application programming interface. As a result, the codefor message passing must be modified when an application program isported to a platform with a different application programming interface.It takes the programmer additional time to replace the message passingcode.

An application programming interface may or may not be written in anobject-oriented language. If the application programming interface iswritten in an object-oriented language, then the application programmermay define classes and class hierarchies as specified in theobject-oriented programming language. Each class may have some functionsassociated with the data in the class. In a class hierarchy, classes areorganized in chains from the general to the more specific. A morespecific subclass is derived from a more general base class. Forexample, if a dialog box were a type of window, then the dialog boxsubclass would be derived from the more general window base class.

Application programming interfaces written in object-orientedprogramming languages have the advantage of allowing the more specificclass to maintain its own data and context and relying on the base classto maintain the general data and context. Therefore, a programmer canreuse code which saves time and can write a more consistently organizedprogram because there is less duplicate code. Each class is independentof other classes, even a subclass is independent of its base class(es),because the class does not need to know about the other classes' data.

Application programming interfaces that are written in object-orientedlanguages have the disadvantage of generating larger programs thatrequire more memory to run. In addition, the application programmer musthave a compiler for the object-oriented language to compile theapplication program. Furthermore, the application programmer must knowthe object-oriented language and be familiar with object-orientedprogramming.

SUMMARY OF THE INVENTION

In accordance with the present invention, there is provided a system andmethod of creating application programs using an application programminginterface. The application programs are multithreaded, portable to otherexisting application programming interfaces, and composed of independentagents. Although the application program is not written in anobject-oriented programming language, the agents may be organized intoclass hierarchies, similar to object-oriented class structures.

The present invention includes an application programming interfacewherein application programs include a collection of agents. An agent isan instance of a particular agent class. Agent classes are defined bythe application programmer. Because new subclass agents may be derivedfrom existing base class agents, the agency application programminginterface provides class hierarchies.

Each agent has three distinct components: a message queue, messagedispatcher, and message processor. An instance of an agent subclass canhave a different message dispatcher and message processor than aninstance of its base class. Because each agent instance has its ownmessage dispatcher and message processor, each agent is aware of its owndata and context. The application programming interface is an "agency"which mediates between the collection of agents that form theapplication and the platform's shared system resources. The agencycommunicates with an individual agent through its message queue. Theagent processes the messages on its queue using its message dispatcherand its message processor.

In addition, each agent is a separate sub-process within an applicationprogram created by using the agency application programming interface.The agency application programming interface contains a masterdispatcher which maintains a list of agents. The master dispatcherselects an agent to activate and activates the selected agent by callingits message dispatcher. When the selected agent is through performingits agency application function it designates itself as inactive. Afterthe agent has designated itself inactive, the master dispatcher resumesrunning and then selects the next agent to activate.

The current thread of execution may be split when the currently activeagent activates the master dispatcher by calling the master dispatcher.The current thread is then suspended until it is reactivated by themaster dispatcher. The master dispatcher reactivates the suspendedthread when it is notified that it should reactivate the thread that wassuspended prior to its being called.

The present invention provides an application programming interface forcreating multithreaded application programs. Since the master dispatcherallocates time among the application program's agents, the agencyapplication programming interface provides non-preemptivemultithreading. Furthermore, the agency application programminginterface provides a means for splitting the currently activated threadand suspending it until it is reactivated. A multithreaded applicationprogram that uses the agency programming interface's multithreadingcapability does not have to be written to conform to the multitaskingprovided by the platform's operating system. Therefore, an agencyapplication program can be ported to a new platform without having torewrite code so that the application program conforms to the newplatform's multitasking capabilities.

Because the agency interface mediates between the platform's sharedsystem resources and an application program's agents, programs createdusing the agency application programming interface can be ported to aplatform with a different programming interface without the need toreplace system dependent code. This saves the programmer the timenecessary to rewrite code. For example, an agency application programwritten to run on a platform with Windows™ could be recompiled to run aplatform with OS/2™ without the need to rewrite portions of the code. Inaddition, the look and feel of the agency application program's userinterface can be ported to the new platform. The user interface of theported version of the agency application program does not have to bemodified to comport with the user interface on the new platform. Forexample, the version of an agency application program that runs onWindows™ could have the same user interface look and feel and theversion of the same agency application program that runs on OS/2™.

Furthermore, since each agent has its own message dispatcher, anapplication programmer may alter the message passing framework providedby the agency programming interface. This allows an agency applicationprogram running on one platform to communicate with an agencyapplication program running on a different platform with a differentapplication programming interface. For example, an agency applicationprogram running on a platform with Windows™ could communicate with anagency application program running on a platform with OS/2™ without aconversion of the messages that are passed.

The present invention also provides classes and class hierarchies in anapplication programming interface written in a non-object-orientedlanguage. Because a subclass agent class can be derived from a baseagent class, the agency interface provides a method for creatingindependent classes of agents which may be hierarchically related toeach other. By using the agency application programming interface,application programmers have the benefits of these features withouthaving to learn an object-oriented programming language and withoutbeing familiar with object-oriented programming. In addition, a compilerfor the object-oriented language is not required and smaller programswhich require less memory to run are generated. Therefore, thisprogramming interface is ideal for application programmers who want towrite application programs with class hierarchies in anon-object-oriented programming language, to run on a system with lessmemory than is necessary to run object-oriented programs.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of apparatus for practicing the presentinvention.

FIG. 2 is a block diagram of the preferred method of defining an agentaccording to the present invention.

FIG. 3 is a flow chart showing operation of an agency applicationprogram according to the present invention.

FIG. 4 is a flow chart showing operation of the master dispatcheraccording to the present invention.

FIG. 5 is a flow chart showing sample operation of an agent's messagedispatcher according to the present invention.

FIG. 6 is a flow chart showing sample operation of an agent's messageprocessor according to the present invention.

FIG. 7A is a flow chart showing the creation of an agent class resourceaccording to the present invention.

FIG. 7B shows agent class resource structure.

FIG. 8 is a flow chart showing sample operation of an agent'sconstructor function according to the present invention.

FIG. 9 is a flow chart showing agent creation in an agency applicationprogram according to the present invention.

FIG. 10 is a flow chart showing agent destruction in an agencyapplication program according to the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now to FIG. 1, there is shown a functional block diagram ofapparatus 100 for practicing the current invention. In the preferredembodiment, the central processing unit (CPU) 101 performs the steps ofthe method, although any type of processor or multiple processors may beused. The agency application 107 resides in memory 110 while the agencyapplication 107 is running. The agency application 107 may reside onhard disk 104 or any other storage device when the agency application107 is not running. In the preferred embodiment, an agency application107 runs as an operating system process 109.

Referring now to FIG. 1, the agency application 107 is linked with theagency application programming interface (API) 115 and therefore, theagency API 115 is part of the agency application 107. The masterdispatcher 108 is part of the agency API 115.

An agency application 107 consists of one or more agents 114 Referringnow to FIG. 2, each agent 114 in the agency application 107 containsthree main parts: a message queue 111, a message dispatcher 112, and amessage processor 113. In addition, the agent 114 contains variouspointers and data structures. The master dispatcher 108 is part of theagency API 115, and maintains a list of the agents in the agencyapplication 107.

The message processor 113 is used by the agent 114 to communicate withthe agency API 115 and to communicate with other agents 114. An agentcommunicates by making calls to the agency API 115.

The agency API 115 supports multithreading because the master dispatcher108 allocates time among the agents 114 within the agency application107. Each agent 114 is a sub-process within the agency applicationprocess. The master dispatcher 108 activates an agent 114 by calling theagent's message dispatcher 112. The message processor 113 is the meansby which the agent 114 performs its application function. When theactivated agent 114 has completed performing its agency applicationfunction, it designates itself as inactive. When an agent 114 designatesitself inactive, the master dispatcher 108 resumes and selects anotheragent 114 to activate. The agency API 115 provides non-preemptivemultithreading by allocating its time slice among the agents 114 in theagency application 107. This is how the agency API 115 providesmultithreading that is independent of the hardware platform'smultithreading capabilities.

An agent 114 also contains a message queue pointer 201 that points toits message queue 111. The message queue 111 consists of a list ofmessages 208. An agent 114 also contains a message processor functionpointer 203 that points to its message processor 113 and a messagedispatcher function pointer 207 that points to its message dispatcher112. The agent 114 contains agent data 209. If the agent class isderived from another agent base class then the agent 114 may containadditional subclass data 210. For example, if a button agent class isderived from a window class agent, the button agent contains window dataand button subclass data.

By defining new agent classes, an application programmer may create acustom user interface for the agency application 107. Because the agencyapplication user interface is created from agents 114, the userinterface can be ported to a platform with a different type of userinterface. Consequently, an agency application 107 running on Windows™can have the same user interface look as the version of that agencyapplication 107 running on XWindows. The agency application's userinterface does not have to be modified to comport with the platform'suser interface. So, the versions of the same agency application 107 fordifferent platforms can have the same user interface.

Referring now to the flow chart of FIG. 3, there is shown a preferredmethod of running an agency application 107. In the preferredembodiment, the steps shown in FIG. 3 are performed by the CPU 101.First, the CPU 101 enters the agency application's 107 main function302. The CPU 101 then opens the agency 303. In this step 303, anyplatform specific operations that must be completed so that the agencyapplication 107 can run are performed. For example, system resources areallocated and structures necessary for the agency API 115 to manageagents 114 are initialized. The CPU 101 then creates agents 114 that arepart of the agency application 304; starts the master dispatcher 305;and then closes the agency 306. In this step 306, system resources aredeallocated and any platform specific operations that were performed inorder for the agency application 107 to run are reversed. Finally theCPU 101 returns from the application 307.

Referring now to the flow chart of FIG. 4, there is shown a preferredmethod of API multithreading. In the preferred embodiment, the stepsshown in FIG. 4 are performed by the CPU 101. First the CPU 101 savesthe agency application context 402. The agency application contextincludes which agent 114 is currently activated, which agent 114currently receives keyboard 105 input and which agent 114 currentlyreceives mouse input. The CPU 101 then checks if the agency active flagis true 403. If the agency active flag is not true, the CPU 101 restoresthe agency application context 404 and returns 406.

If the agency active flag is true, the master dispatcher 108 selects anagent 114 to activate 405 and then calls the selected agent's messagedispatcher 407. The selected agent 114 is activated and runs until ithas completed its agency application function. When the selected agentdesignates itself as inactive, the master dispatcher 108 resumes anddistributes system events to the appropriate agents' message queues 408.This is how the agency API 115 mediates between the agency application107 and system resources. The agency application 107 is portable becauseit does not make direct system calls. However, an agent's 114 messagedispatcher 112 may directly access system resources. This makes theagency API 115 flexible.

A thread of execution can be split when the currently activated agent114 activates the master dispatcher 108 by calling the master dispatcher108. The current agent's thread is then suspended until the masterdispatcher 108 reactivates the thread. The master dispatcher 108 resumesrunning and selects an agent to activate. The master dispatcher 108 mayselect the agent 114 whose thread was previously suspended. The masterdispatcher 108 is notified, by a call to the agency API 115 that setsthe agency active flag to false, that it should stop the selection andactivation of agents, and reactivate the thread that was suspended priorto the call to the master dispatcher 108. When the master dispatcher 108determines that the agency active flag is false 403, it restores theagency application context 404 and returns 406. The suspended agentthread is thereby reactivated.

Referring now to FIG. 5, there is shown a flow chart of an example ofthe operation of an agent's message dispatcher 112. In the preferredembodiment, the steps shown in FIG. 2 are performed by the CPU 101. TheCPU 101 checks if the agent 114 is running 502. If the agent 114 is notrunning it returns 503 and the agent 114 is designated as inactive. TheCPU 101 then checks if the agent 114 is yielding its time 504; if theagent 114 is yielding its time, the CPU 101 returns 503. The CPU 101then checks if a message exists in the message queue 505. If there areno messages 208 in the message queue 111, the CPU 101 returns 503.

If there is a message 208 in the message queue 111, the message 208 isdispatched 506 to the agent's message processor 113. The CPU 101 thenreleases the memory for the message 507 and may perform optionaladditional work 508 before checking if the agent 114 is running 502again. An agent's message dispatcher 112 may do what an applicationprogrammer chooses for it to do. Therefore, the agency API 115 isflexible. The only requirement is that at some point the agent's 114message dispatcher 112 designates itself inactive so that the masterdispatcher 108 can resume.

The agent's message dispatcher may be written differently than theexample message dispatcher 112. For example an agent's messagedispatcher 112 could be written so that the agent 114 has three messagequeues or so that the agent 114 takes messages 208 from another agent'smessage queue 113. An agent may collect information from other sourcesbesides its own message queue 113. This allows the applicationprogrammer to alter the message passing framework provided by the agencyAPI 115. Therefore, an agency application 115 running on one platformcan communicate with an agency application 115 running on a differentplatform with a different operating system without converting themessage passing code.

Referring now to FIG. 6, there is shown a flow chart of an example ofthe operation of an agent's message processor 113. In the preferredembodiment, the steps shown in FIG. 6 are performed by the CPU 101.First the CPU 101 checks if the message 208 applies to the agent class602. If the message 208 does not apply to the agent class, the CPU 101relays the message to the base class 605 by calling the base classmessage processor 113 and then returns 606.

If the message 208 applies, the message processor 113 processes theportion of the message 208 that applies to the agent's specific classdata 603. The CPU 101 then checks if the agent's base class needs themessage 604. If not, the message processor 113 returns 606. If the baseclass needs the message 208, the message 208 is relayed to the baseclass 605 by calling the base class message processor 113. This is howeach agent 114 subclass remains independent of its base class(es). Theagent's 114 message processor only has to update its specific subclassdata 210; it then calls the base class message processor 113 to updatethe general base class data. The CPU 101 then returns 606.

Referring now to FIG. 7A, there is shown a flow chart for an agent'sresource constructor function. FIG. 7B shows the agent class resource706, which provides the programmer with the ability to modify thedefinition of an agent 114 without changing the agency application code.The agency class resource 706 contains information 707, 708,709, 710necessary to create an agent instance. In the preferred embodiment, thesteps shown in FIG. 7 are performed by the CPU 101. Agents 114 arecreated 304 after the agency is opened 303. Agents also can be createdbefore the master dispatcher is started 305 and can be created by anagent's message processor 113.

Creating or loading an agent class resource 706 is part of the processof creating an agent instance. First the agent's structure and data aredefined through the creation or definition of an agent class resource706. If an agent class resource 706 exists, it is loaded into memory110. To create an agent class resource 706, the CPU 101 calls the classresource constructor function. Each class resource constructor functionfollows these basic steps. First, the CPU 101 checks 702 if resourcememory 110 is provided. If memory 110 is not provided, the CPU 101returns 705. If memory 110 is provided, the CPU 101 calls the agent'sbase class resource constructor function 703 and then assigns theagent's specific class data to the resource 704. The CPU 101 thenreturns 705. Once the agent class resource 706 has been created orloaded, it is used to create one or more agent instances.

Referring now to FIG. 8, there is shown a flow chart for an agent'sconstructor function. In the preferred embodiment, the steps shown inFIG. 8 are performed by the CPU 101. First the CPU 101 calls the agent'sbase class constructor 802. Every agent has at least one base classbecause the agent class is a base class of all agents. The CPU 101 thentransfers specific class resource data to the agent structure 803. Forexample, if a button agent class is a subclass of a window agent class,the window agent's constructor is called and then the button agent'sresource data is transferred into the button agent's subclass data 211.

Next, the CPU 101 assigns the agent its class' message processor 804 andreturns 805. Every agent class has a constructor function of this form.Each agent class remains independent because each agent 114 onlytransfers specific class data and relies on the base class constructorfunction to transfer the general class data.

Referring now to FIG. 9, there is shown a flow chart for the placementof an agent 114 in its context. This is the next step in the creation ofan agent instance. The agent's context is its position relative to otheragents 114 in the agency application 107. An agent has parents,siblings, and children, which are set to define its position within theagency application 107. For example, if there are currently four windowagents 114 open and displayed in the agency application 107, then thewindows may overlap each other on the screen 106. Each level of overlapis a layer on the screen 106. The parent, children, and sibling pointersindicate which agents are in the layer behind, in the layer in front of,and in the same layer as the window agent 114.

In the preferred embodiment, the steps shown in FIG. 9 are performed bythe CPU 101. First the CPU 101 calls the agent constructor function 902.The CPU 101 then assigns a message dispatcher 112 to the agent 903. Nextthe CPU 101 assigns the agent to its parent 904, attaches the agent toits appropriate agency lists 905, and sends a construct message forimmediate response 905 to the agent 114 In response to a constructmessage, an agent 114, if necessary, allocates and initializes any classspecific instance data or storage space. The CPU 101 then returns theagent 907. After each agent 114 is created and initialized 304 theagency master dispatcher is started 305 and the agency application 107runs until the master dispatcher 108 returns.

Referring now to FIG. 10, there is shown a flow chaff for thedestruction of an agent instance. All agents 114 are destroyed beforethe agency application 107 has completed execution; however agents 114can be destroyed at any time during the execution of the agencyapplication 107. In the preferred embodiment, the steps shown in FIG. 10are performed by the CPU 101.

The CPU 101 first sends a destruct message for immediate response 1002to the agent 114. The CPU 101 then destroys children agents 1003;releases allocated system resources 1004 including pending messages 208;removes the agent from the agency lists 1005 including themultithreading list maintained by the master dispatcher 108; and finallyreleases memory 110 for the agent instance 1006 before returning 1007.

What is claimed is:
 1. A system for implementing an agent-basedapplication program on a computer, comprising:a processor; an inputdevice coupled to the processor, for accepting input; an output devicecoupled to the processor, for providing output; memory unit coupled tothe processor, for storing data and program instructions; an operatingsystem, stored in the memory and managing a plurality of processescreated by execution of program instructions in the memory unit by theprocessor; and at least one agency application unit coupled to theprocessor and managing a plurality of agents stored in the memory unit,and including:a master dispatcher coupled to the plurality of agents,for receiving from, and sending messages to the agents, and responsiveto all agents being inactive, selecting an agent and activating theselected agent; the plurality of agents, each agent responsive to beingactivated by the master dispatcher, for executing an applicationfunction, each agent comprising:a message dispatcher for receiving asignal from the master dispatcher activating the agent, and fordispatching at least one message providing for execution of theapplication function; at least one message queue, for receiving andstoring at least one message from the master dispatcher and from othersources, and operatively coupled to the message dispatcher andresponsive to the agent being active, for passing at least one storedmessage to the message dispatcher for dispatching; and a messageprocessor operatively coupled to the message dispatcher and receiving adispatched message, for executing the application function of thereceived message.
 2. The system of claim 1, wherein each agent,responsive to completing at least one application function, designatesitself as inactive.
 3. The system of claim 1, wherein:the agencyapplication unit further includes an agent list coupled to the masterdispatcher; and the master dispatcher selects a first agent from theagent list, and activates the first agent by invoking the first agent'smessage dispatcher, the first agent executing selected processes withthe processor, such that the master dispatcher waits to select oractivate a second agent until the first agent has designated itselfinactive.
 4. The system of claim 1, wherein the message processor of afirst agents calls the master dispatcher of the agency application unit,the master dispatcher suspending the first agent, selecting at least onesecond agent, and activating the second agent, and unsuspending thefirst agent when the second agent designates itself inactive.
 5. Thesystem of claim 1, wherein the message dispatcher of an activated agentretrieves a message stored in a message queue of a deactivated agent,and passes the retrieved message to the message processor of theactivated agent for executing the application function of the retrievedmessage.
 6. The system of claim 1, wherein the message dispatcher of anactivated agent stores a message in a message queue of a deactivatedagent.
 7. The system of claim 1, wherein there is a base agent class,and a plurality of agent subclasses derived from the base agent class,and wherein there is an agent list, each agent in the agent list beingan instance of one agent subclass, wherein:the message processor of anactivated agent determines whether a received message applies to theagent subclass of which the activated agent is an instance; responsiveto the received message applying to the agent subclass, executing theapplication function of the received message; and responsive to thereceived message not applying to the agent subclass, calling a baseclass message processor, the base class message processor executing theapplication function of the received message.
 8. The system of claim 1,wherein the message dispatcher dispatches messages from the messagequeue to the message processor until the message queue is empty.
 9. Thesystem of claim 1, wherein the message dispatcher dispatches messagesfrom the message queue to the message processor until the agent signalsthat it is yielding its time, the message dispatcher deactivating theagent.
 10. The system of claim 1, wherein the message dispatcher createsa process for execution by the processor in addition to any applicationfunctions executed by the message processor.
 11. The system of claim 1,wherein the master dispatcher preemptively activates a selected agent.12. A computer-implemented process for controlling agent operation in anagent-based application program having a plurality of agents, comprisingthe steps of:responsive to all agents being inactive, performing thesubsteps of:selecting an agent; and activating the selected agent;responsive to at least one agent being active, the agent performing theoperations of:receiving at least one message from a source external tothe agent, or from the agent itself, the message providing for theexecution of an application function; storing received messages in amessage queue coupled to the agent; determining if the message queuecontains at least one message; responsive to the message queuecontaining at least one message,removing a message from the messagequeue and performing an application function according to the message;and responsive to the message queue being empty, designating the agentas inactive.
 13. The method of claim 12, wherein an agent furtherperforms the operations of:selecting one of a plurality of messagesqueues, each message queue for storing a plurality of messages; andstoring a received message in the selected message queue.
 14. The methodof claim 12, wherein the step of receiving at least one message furthercomprises the substeps of:retrieving a message stored in a message queueof a deactivated agent.
 15. The method of claim 12, further comprisingthe operation of:storing a message in a message queue of a deactivatedagent.
 16. The method of claim 12, wherein the steps of removing themessage from the message queue and performing the application functionaccording to the message are performed until the message queue is empty.17. The method of claim 12, wherein the steps of removing the messagefrom the message queue and performing the application function accordingto the message are performed until the agent yields its time.
 18. Themethod of claim 12, wherein the step of activating the selected agent isperformed preemptively.
 19. The method of claim 12, further comprisingthe step of the message dispatcher of an activated agent creating aprocess for execution by a processor in addition to any applicationfunction executed by the message processor.